chore(e2e): run Playwright visual tests in Docker (#DS-5311) - #1889

Backport of #1845 and #1886 from main.

The screenshot baselines are compared with threshold: 0 and carry no
{platform} suffix, so they belong to one OS and one browser build. Until
now a developer could neither run nor regenerate them off CI, and CI
itself was pinned only by whatever ubuntu-latest meant that week.

Deliberate divergences from main, none of which have a counterpart there:

- the base image is pinned to the v1.55.0-noble digest, matching this
  branch's Playwright rather than main's 1.62.1;
- @playwright/test drops its caret. It already resolved to 1.55.0, so
  nothing installed changes, but tools/e2e/run.js needs an exact version
  to name an image tag, and a patch bump moves the bundled Chromium and
  invalidates every baseline;
- packages/cdk joins the build-context allowlist. 73 files under
  packages/components import @koobiq/cdk/{a11y,keycodes,testing}; on main
  the CDK lives inside components/core and needs no entry;
- the ignore rules land in .eslintignore, since this branch predates the
  flat config;
- everything about the docs smoke suite is dropped - there is no
  e2e:docs script and no playwright.docs.config.ts here.

No baseline is regenerated: all 182 pass unchanged inside the container.

docker compose creates a missing bind-mount source itself, but the daemon
does it - so against a rootful daemon playwright-report/ and test-results/
land in the working tree owned by root, and the developer's next run cannot
write into them. It does not heal itself either: the ownership survives
until someone with sudo removes the directories, and the error it eventually
produces comes from inside the container, pointing nowhere near the cause.

Both CI workflows already carried a `mkdir -p` for exactly this, but
tools/e2e/run.js did not, so a plain local run stayed exposed. Creating them
in the wrapper covers every supported entry point, and the workflow steps go
away rather than duplicating it.

It could not be rendered truthfully. A kbq-dropdown-item only exists inside
an overlay, so the previous version opened the dropdown and captured
whatever of the panel happened to overlap the component's bounding box -
clipped at the edge, and timed against the open animation, which is what
made the test flaky in the first place. Rendering the item inline instead
traded that for importing the dropdown's own stylesheets into this page to
fake the appearance, which is no more honest.

The appearance of an item with an icon is already covered by the dropdown
suite, in a real panel. What is lost here is the icon resolved as inline SVG
rather than as a font class, which is a thin enough distinction not to be
worth either fake.